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DETAILED ACTION 

1 . The Office Action is responsive to the communication filed on 7/26/20 10. 

2. Claims 1-2, 5, 8-13, 15-19, 21-26, 28-30, 32, 34-39, 41-42, and 44-49 are pending. 

Continued Examination Under 37 CFR 1.114 

3 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 7/26/2010 has been entered. 

Response to Amendment 

4. The amendment, filed 07/26/2010, has been entered. 

Response to Arguments 

Applicant's arguments filed 07/26/2010 have been fully considered but they are not persuasive 
with respect to the normalization module. Applicant's specification, paragraphs [0051], [0052], 
[0064], [0066], [0067], [0071], and [0096] enumerate the functionality of the normalization 
module. As understood, the normalization module functions to facilitate the querying and 
configuring of devices. In particular, the function is articulated as 1) providing network driver 
capabilities/status and 2) specifying, by the rules engine, configuration commands to the media 
specific drivers. The structure of the module may exist as an application layer and/or be 
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incorporated into either the rules engine or the media specific module. In support, the 
specification, paragraph [0051], elaborates the function and structure of the normalization 
module. 

[ 0051] The media specific modules 320 are associated with two interfaces. The media specific 
modules 320 communicate with the rules engine via a generalized interface incorporated into a media specific 
normalization module 322. The normalization module 322, a layer that sits between the rules engine 300 and the 
media specific modules 320, facilitates standardizing communications between the rules engine 300 and media 
specific modules 320 of many types. The normalization module 322 facilitates: providing network driver 
capabilities/status information from the media specific modules 320 to the rules engine 300, and (2) specifying, by 
the rules engine 300, network interface configuration commands to the media specific drivers 302 via the media 
specific modules 320. Furthermore, the user-mode media specific modules 320 communicate with the media 
specific drivers 302, for example, according to (kernel mode) network driver interface specification (NDIS) 340. 
While the illustrative embodiment provides a media specific module for a particular medium type or class of media 
types, it is contemplated that alternative embodiments of the invention include composite media specific modules 
that support multiple, unrelated media types (e.g., a WWAN/WLAN media specific module). Furthermore, while the 
normalization module 322 is shown as a separate entity from both the rules engine 300 and the media specific 
modules 320, in alternative embodiments of the invention the functionality of the normalization module is 
incorporated into either the rules engine 300 or the media specific modules 320. 



The normalization module is interpreted as providing at least two functions of facilitating 
both status retrieval and configuring respective interface card (e.g., The normalization module322 

facilitates: providing network driver capabilities/status information from the media specific modules 320 to the rules 
engine 300, and (2) specifying, by the rules engine 300, network interface configuration commands to the media 
specific drivers 302 via the media specific modules 320) Although Melpignano et al. teaches these 
functions in separate code (IfPriority and IfStatus), the code may nevertheless be integrated into 
a single module. Furthermore, this module may be incorporated as part of the Network Interface 
Class either as a separate or integrated module (e.g., in alternative embodiments of the invention the 
functionality of the normalization module is incorporated into either the rules engine 300 or the media specific 
modules). 

As per MPEP Section 2144.04 [R-6] V. Making Portable, Integral, Separable, Adjustable, or 
Continuous, the functionality of two modules may be integrated into a single module. 
Melpignano et al. teaches a media specific module interface incorporating separate modules or 



Application/Control Number: 10/693,655 Page 4 

Art Unit: 2121 

code for facilitating the function of 1) providing status information (IfStatusFlags) and 2) 
configuration commands (IfPriority) ([0050] e.g., a priority can be dynamically changed by the 
IfManager, i.e., rules engine, much in the same way that the normalization module functions to 
provide configuration commands to the network interfaces. These modules may be integrated 
into a unified module where this module performs a substantially similar functionality of 
facilitating both status information and configuring a network interface. 

As applied to applicant's amendment, this module converts standardized communication 
requests it receives from the rules engine into media specific communications that meet media 
specific implementation requirements (e.g., IfPriority is a function of setting the priority per 
network interface card. It is media specific because the priority is set per card. Media specific 
implementation requirements correspond to setting a priority for an interface based on at least 
user specification, card capabilities, etc. Second, IfStatus functions to retrieve the status per 
interface card that is best understood as directing media specific communications (e.g., status 
request) to respective network interfaces. 

In effect, an integrated module provides the function of 1] configuring a priority of an 
interface using an IfManager, i.e., rules engine (e.g., converts standardized communication 
requests it receives from the rules engine into media specific communications that meet media 
specific implementation requirements) and 2] requesting status information per interface (e.g., 
configured to direct media specific communications to respective network interfaces) 

The above discussion is incorporated into the newly added claim limitations with regard to a 
normalization module. 



Application/Control Number: 10/693,655 
Art Unit: 2121 



Page 5 



Allowable Subject Matter 

5. The following is a statement of reasons for the indication of allowable subject matter. 
Independent claim 1 recites A] a plurality of media specific modules configured to acquire network 
interface information pertaining to network interfaces associated with particular media types, and to 
receive network interface configuration commands, from the rules engine, to connect to one of the set of 
networks, each of the media specific modules configured to acguire network interface information from 
media specific drivers associated with particular interfaces, and B] the media module interface 
comprising a normalization module that converts standardized communication requests it 
receives from the rules engine into media specific communications that meet media specific 
implementation requirements, the normalization module further configured to direct the media 
specific communications to respective network interface. 

6. The combination of the media module interface comprising a normalization module (e.g., 
structural configuration) and associated functions (e.g., converting standardized requests from a 
rules engine and directing commands to respective interfaces) combined with the newly added 
limitations, supra A], are not taught by the prior art, alone or in combination. 



Claim Rejections - 35 USC §103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 
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8. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. I, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

7. Claims 15-19, 21-26, and 41-42 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Melpignano et al. (USPN 2006/0084417 Al) in view over Babbar et al. 
(USPN 2004/01 16140 Al) and in view over Shi (USPN 6807163) and in further view over Shi 
(USPN 20040192301) 

8. As per claim 15, Melpignano et al. teaches a method for selecting a network and interface 
combination, to which a computing system will initiate a connection via the network interface, 
based upon network information spanning multiple communication media, the method 
comprising: 

accessing a network selection criteria acquired from a plurality of sources ([0039], [0049 - 
suitable main classes of NISP], [FIG 3 -elements 200, 202, 210, 214] e.g., plurality of sources, 
not defined, may comprise multiple sources including user preferences, predefined sets or 
personal policies, and/or classes (AccessPoint, Networklnterface, and Context) where each class 
represents a source of information pertinent to selecting an appropriate interface) 

accumulating network interface information ([0050 - element 202] e.g., plurality of interface 
cards and associated, class information, further including status information) potentially 
spanning multiple communication media ([0033] e.g., data, fax, video, or speech, and/or Wlan, 
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bluestooth) , the accumulated network interface information being associated with a set of 
networks (e.g., WLAN, WPAN) and a set of network interfaces ([0033 lines 3-4]), each network 
interface for connecting the computing system to a network in the set of networks (e.g., 
connectivity to server via networks), the accumulating facilitated by a normalization module 
(e.g., supra claim 1) that converts standardized commands it receives from a rules engine into 
media specific commands to a set of media specific modules (e.g., supra claim 1) ; and 

designating, via the rules engine ([0049], [0055]), one of the set of networks and a network 
interface from the set of network interfaces by applying a network selection criterion to the 
network interface information potentially spanning multiple media ([0053-55] e.g., IfManager 
takes care of interface connectivity, management, and selection being performed by choosing the 
best interface according to context and user preferences.) 

However, Melpignano et al. does not teach that network selection criteria is acquired from at 
least one of a group policy service. Babbar et al. teaches a service level agreement ([0009] e.g., 
a group policy is interpreted as an agreement between at least two entities, the agreement 
providing communication rules between the entities. A contract/agreement pertaining to service 
provisioning is a group policy) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a service level agreement as part of the network selection criteria. Babbar 
et al. teaches that mobile users gain access to network services from a terminal. Service level 
agreements provide enhanced access to services, including cost, reliability, priority, protection 
from unauthorized access, and system throughput. Melpignano et al. teaches that network 
selection may be based upon security, costs, data transfer speed, and cached context information. 
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In effect, because service level agreements illustrate additional selection criteria, it would have 
been beneficial to acquire network selection criteria, as provided by the service level agreement, 
as part of selecting an optimal network. 

Melpignano et al. teaches initiating network scanning ([0040], [0057], [FIGure 3-element 
200 (ImScanning Type) for a designated one or more set of network interfaces ([0055-56]) 
based at least in part upon a scanning algorithm ([Figure 3-element 200, [0057] ) that adaptively 
changes a scanning frequency ([0057], [0074-75] e.g., scanning frequency is interpreted as how 
often an entity is checked. Here, an access point may be scanned when a poll interval expires or 
it can be awaked after a new access point wireless event). However, Melpignano et al. does not 
disclose adjusting the frequency based on previous scan results. Shi teaches an adaptive rate 
channel scanning method for adaptively changing the scan rate based on data stored in a channel 
table during previous channels scanned by the channel scan process ([COL 4 lines 30-41) Note: 
Shi is also introduced to address the narrow limitations of the applicant's specification regarding 
the scan rate (should applicant further define 'adapting') 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to adaptively change the scan rate based on previous scan results to adapt to changing 
network conditions as a means to save battery power. Melpignano et al. teaches scanning for 
available access points at periodic intervals. Shi teaches changing the scanning rate based on 
previous scan results to conserve battery power. Since adaptively selecting a scan rate as a 
function of network conditions (as assessed via previous scan results) saves power, it would have 
been obvious to modify Melpignano et al. to adapt the scan rate based on previous scans. 
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Shi teaches a programming interface ([Figure 3] coupled to a user interface, the programming 
interface configured to provide commands for the multiple communication media in a common 
format based on user input through the user interface ([0018], [0021], [0025-26]) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a programming interface so as to enable a user to enter specific 
preferences. Melpignano et al. teaches enabling a user to enter preferences ([0039]). Shi teaches 
a programming interface to enable a user to enter preferences. It would have been obvious to 
provide a means to program network references via a programming interface, as per Shi. 

9. As per claim 16, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion is accessed from a configurable rules data store ([0039] e.g., user preferences 
implies that a user may modify a policy) 

10. As per claim 17, Melpignano et al. teaches the method of claim 15 further comprising 
issuing network interface configuration instructions in accordance with the designating step 
([0039 lines 8-11]) 

11. As per claim 18, Melpignano et al. teaches the method of claim 1 5 wherein the media 
specific modules (e.g., Bluetooth, Wlan, etc) are each associated with at least one distinct type 
of communication media driver ([0049] e.g., MWAL handles all drivers for each interface. It is 
implied that there is a unique driver per module, i.e., Bluetooth, Wlan, GPRS, etc) 

12. As per claim 19, Melpignano et al. teaches the method of claim 18 further comprising 
acquiring, by the media specific modules (e.g., interfaces), network interface information from 
the communication media drivers associated with particular network interfaces ([0049-50] e.g., it 
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is understood that interface device drivers provide status, capability, and list of reachable access 
points for a respective interface) 

13. As per claim 21, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between at least two media based upon a network 
parameter associated with the media ([0050] fPriority, [0036] - NISP) 

14. As per claim 22, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between at least two media based upon a network 
type associated with the media ([0050] fType) 

15. As per claim 23, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order based upon a current location of the computing 
system ([0052] e.g., location) 

16. As per claim 24, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between logical networks ([0033] e.g., WLAN, 
PWAN], [0050] e.g., fPriority) 

17. As per claim 25, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order based upon a network time of use parameter 
([0051] e.g., 'already visited or not'). 

18. As per claim 26, Melpignano et al. teaches the method of claim 15 wherein the 
designating comprises evaluating in a rules engine at least one of the network selection criteria 
based on the accumulated network interface information ([0053-56]), and the method further 
comprises cyclically performing, under the control of a state machine: scanning a set of network 
interfaces for networks ([0057], [FIG 4]); applying, with the rules engine, the network selection 
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criterion to a set of networks and interfaces to render a current network and interface selection 
([0054]); and issuing configuration instructions in accordance with the current network and 
interface selection ([0054], [0070-72] e.g., connectivity, management, and selection implies that 
a selected card is configured accordingly. For example, insertion/removal of a card entails a new 
configuration) 

19. As per claim 41, Melpignano et al, as modified, teaches wherein the rules data store 
maintains network selection criteria from a plurality of sources ([0039-GUI]) and a group policy 
service (e.g., supra discussion on claim 15 pertaining to service level agreements) 

20. As per claim 42, Babbar et al. teaches the computing system of claim 41 wherein the 
sources network selection criteria are acquired from include a provisioning service ([0009- 
Quality of Service provisions relating to the delivery of services and content as part of the 
service level agreement) 

21 . Claims 28-32, 34-39, and 45-47 rejected under 35 U.S.C. 103(a) as being unpatentable 
over Melpignano et al. (USPN 2006/0084417 Al) in further view of Shi (USPN 6807163) and in 
further view over Nguyen (PGPub 20030212784) 

22. As per claim 28, Melpignano et al. teaches a computer-readable medium including 
computer-executable instructions for facilitating selecting a network and interface combination, 
to which a computing system will initiate a connection via the network interface, based upon 
network information spanning multiple communication media, the computer-executable 
instructions facilitating: 

accessing network selection criteria acquired from a plurality of sources ([0039], [0049 - 
suitable main classes of NISP], [FIG 3 -elements 200, 202, 210, 214] e.g., plurality of sources, 
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not defined, may comprise multiple sources including user preferences, predefined sets or 
personal policies, and/or classes (AccessPoint, Networklnterface, and Context) where each class 
represents a source of information pertinent to selecting an appropriate interface; 

accumulating network interface information comprising status and capability information 
(Figure 3-element 202] e.g., IfStatus and IfReachable, IfRemovable) for each of multiple 
communication media ([0033] e.g., data, fax, video, or speech, and/or Wlan, bluestooth) 
associated with a set of networks (e.g., WLAN, WPAN) and a set of network interfaces ([0033 
lines 3-4]), each network interface for connecting the computing system to a network in the set 
of networks (e.g., connectivity to server via network), 

However, Melpignano et al. does not teach that the accumulating is facilitated by a 
normalization module that provides an interface (e.g., as per Melpignao, Figure 3 -element 202) 
that standardizes communication between a set of media specific modules and a rules engine. 
Nguyen teaches a network fault monitoring module ([0019], [0021], [0027] e.g., A normalization 
module, in light of applicant's specification, is interpreted as providing network status 
information. Applicant's specification teaches that the normalization module standardizes 
communication via providing status information from the media specific modules to the rules 
engine) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a module to relay the status information from the Networklnterface class 
to the IfManager. Melpignano et al. teaches that the rules engine (e.g., IfManager) continuously 
monitors the network interface availability. Since multiple interfaces are provided, it is 
beneficial to accumulate and relay the status of each interface to the IfManager such that an 
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appropriate interface may be selected. Since a network fault module, as taught by Nguyen, 
provides interface status information to other modules, it would have been obvious to include 
this module as part of the networkinterface class as part of the standard communication between 
the rules engine and network interface class;); and 

designating, via the rules engine ([0049], [0055]), one of the set of networks and a network 
interface from the set of network interfaces by applying a network selection criterion to the 
network interface information potentially for the multiple media ([0053-55] e.g., IfManager takes 
care of interface connectivity, management, and selection being performed by choosing the best 
interface according to context and user preferences) 

23. As per claim 29, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion is accessed from a configurable rules data store ([0036] 
e.g. NISP) 

24. As per claim 30, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the computer-executable instructions further facilitate issuing network interface 
configuration instructions in accordance with the designating step ([0054], [0070-72] e.g., 
connectivity, management, and selection implies that a selected card is configured accordingly. 
For example, insertion/removal of a card entails a new configuration) 

25. As per claim 32, Melpignano et al. teaches the computer-readable medium of claim 3 1 
further comprising computer- executable instructions for acquiring, by the media specific 
modules, network interface information from the communication media drivers associated with 
particular network interfaces ([0049-50] e.g., it is understood that interface device drivers 
provide status, capability, and list of reachable access points for a respective interface) 
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26. As per claim 34, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between at least two media 
based upon a network parameter associated with the media ([0050] e.g., physical characteristics) 

27. As per claim 35, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between at least two media 
based upon a network type associated with the media([0050] fType) 

28. As per claim 36, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order based upon a current location 
of the computing system ([0052] e.g., location) 

29. As per claim 37, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between logical networks 
([0050] e.g. WLAN, WPAN) 

30. As per claim 38, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order based upon a network time 
of use parameter ([005 1] e.g., 'already been visited') 

31. As per claim 39, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein machine the computer-executable instructions comprises a rules engine for evaluating at 
least one of the network selection criteria based on the accumulated network interface 
information ([0053] e.g., IfManager), and further comprising computer-executable instructions 
for cyclically performing, under the control of a state machine: scanning a set of network 
interfaces for networks ([0057], [FIG 4]); applying, with the rules engine, the network selection 
criterion to a set of networks and interfaces to render a current network and interface selection 
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([0054]); and issuing configuration instructions in accordance with the current network and 
interface selection ([0054], [0070-72] e.g., connectivity, management, and selection implies that 
a selected card is configured accordingly. For example, insertion/removal of a card entails a new 
configuration) 

32. As per claim 44, Babbar et al. teaches the method of claim 28 wherein the plurality of 
sources of the network selection criteria are acquired from include a provisioning service ([0009- 
([0009- Quality of Service provisions relating to the delivery of services and content as part of 
the service level agreement) 

33. As per claim 45, Shi teaches the computing system of claim 1, wherein the scanning 
engine increases the scanning delay period when the plurality of previous scans indicate there is 
no change in state ([COL 2 lines 1-15], [COL 4 lines 55-60], [COL 4 lines 14-20] e.g., a state 
change is viewed in comparison to the number of LBT channels. One state would be a 
substantial number of LBT channels necessitating minimizing the scan rate. Another state would 
be an indication that the user is in a cell overlap area requiring a higher scan rate) 

34. As per claim 46, Shi teaches the computing system of claim 1 , wherein the scanning 
engine performs a scan when the plurality of previous scans indicate movement of the computing 
system ([COL 1 lines 65-67], [COL 4 lines 35-40]) 

35. As per claim 47, Shi teaches the computing system of claim 46, wherein the scanning 
engine determines the computing system is moving based on at least one of received signal 
strength ([COL 53-65], [COL 6 lines 1-13] e.g., comparison on RSSI values during a handover, 
i.e., movement) , retransmission counts, or frame error rates.) 
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36. Claim 48 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et al. 
(USPN 2006/0084417 Al) in view of Shi (USPN 6807163), and in further view over Hartless et 
al. (USPN 6292660) 

37. As per claim 48, Hartless et al. teaches the computing system of claim 1, wherein the 
scanning engine ([Figure 3-element 14] e.g., Melpignano et al. also teaches a scanning engine, 
which may be modified to include the functionality of element 14, as per Hartless) is configured 
to detect a network interface to be scanned is sending traffic ([Col 4 lines 4-8], [Col 5 linesl5- 
20] e.g., traffic, i.e., signals, are used to determine motion of the mobile device. It is determined 
that the mobile is sending traffic, i.e., in communication with a site, via analyzing signals. A low 
fade rate would imply that the mobile is not moving but determined to be in communication with 
a site. When it is determined that the mobile is not moving, it is therefore not necessary to scan 
at a particular interval because the mobile is determined to be in communication with a site and 
not moving between sites), the scanning engine analyzes statistics (e.g., a statistic is interpreted 
as a collection of quantitative data, i.e., signal, frequency, velocity, etc ) for the traffic (e.g., 
signals are processed by equation (1) to provide motion estimate) to determine whether a 
scanning period is to be skipped ([Col 5 lines 4-5] e.g. site scanning is not needed) 

Therefore, at the time the invention was made, it would have been obvious to determine 
that that mobile phone is in communication with a site and not moving to determine whether to 
skip scanning period, i.e., skipping a scan interval. Traffic is analyzed (e.g., analyzing signals, 
which are measured. This measurement(e.g., signal) along with the determined frequency 
provide a collection of quantitative data (e.g., frequency, signal strength, velocity, , i.e., statistics, 
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which are used in determining motion). Alternatively, as per Table 1, multiple scan periods are 
depicted. One period may be skipped in lieu of another based on the aforementioned analysis. 

48. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et 
al. (USPN 2006/0084417 Al) in view of Shi (USPN 6807163), in view over Hawkins (USPN 
7025209), and in further view over Lemilainen et al. (USPN 6681259) 

49. As per claim 49, Melpignano et al. teaches the computer-readable medium of claim 28, 
further comprising: 

receiving a notification that a new network interface is available ([0070-72] e.g., hardware 
update. It is obvious that interfaces may be added and removed); and 

However, Melpignano et al. docs not teach loading another media specific module (e.g. 
network class information. It is obvious to have one class per network interface, providing a 
plurality of classes. One class corresponds to Bluetooth (e.g., type, status), another class 
corresponds to Wlan (e.g. type, status). Each class equates to a module. When a new interface 
is added, a new module is created, as per Hawkins, see below) corresponding to said new 
network interface,. Hawkins teaches installing a network interface module, i.e., loading a media 
specific module, which would correspond to the new interface hardware, such as Bluetooth, 
where such modules contain code (e.g., drivers) configured to provide network information 
([Col 101 lines 6-14]) 

However, Melpignano et al., as modified (e.g., one class per interface type, where a class is a 
module), does not teach said media specific module (e.g., networkclass) configured to request 
network interface information from a driver for said network interface. Lemilainen et al. 
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teaches NIC drivers provide features and state information ([Col 10 lines 1 1-30] e.g., this 
illustrates that drivers provide status information) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to enable the networkinterface class (e.g., module) to request status information using 
network interface drivers. Melpignano et al teaches that interface status is requested - element 
202 (ifStatusFlags). Lemilainen et al. teaches NIC drivers provide status information. 
Therefore, it would have been obvious to use NIC drivers to relay state information to the 
networkinterface module -element 202. As modified, there is a network interface module 
(element 202) for each type of module (e.g., Bluetooth, GPRS, WLan). As new interface cards 
are added, a new module, as per Hawkins, is added to reflect this addition. 

38. Claim 48 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et al. 
(USPN 2006/0084417 Al) in view of Shi (USPN 6807163), and in further view over Hartless et 
al. (USPN 6292660) 

39. As per claim 48, Hartless et al. teaches the computing system of claim 1, wherein the 
scanning engine ([Figure 3-element 14] e.g., Melpignano et al. also teaches a scanning engine, 
which may be modified to include the functionality of element 14, as per Hartless) is configured 
to detect a network interface to be scanned is sending traffic ([Col 4 lines 4-8], [Col 5 linesl5- 
20] e.g., traffic, i.e., signals, are used to determine motion of the mobile device. It is determined 
that the mobile is sending traffic, i.e., in communication with a site, via analyzing signals. A low 
fade rate would imply that the mobile is not moving but determined to be in communication with 
a site. When it is determined that the mobile is not moving, it is therefore not necessary to scan 
at a particular interval because the mobile is determined to be in communication with a site and 
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not moving between sites), the scanning engine analyzes statistics (e.g., a statistic is interpreted 
as a collection of quantitative data, i.e., signal, frequency, velocity, etc ) for the traffic (e.g., 
signals are processed by equation (1) to provide motion estimate) to determine whether a 
scanning period is to be skipped ([Col 5 lines 4-5] e.g. site scanning is not needed) 

Therefore, at the time the invention was made, it would have been obvious to determine 
that that mobile phone is in communication with a site and not moving to determine whether to 
skip scanning period, i.e., skipping a scan interval. Traffic is analyzed (e.g., analyzing signals, 
which are measured. This measurement(c.g., signal) along with the determined frequency 
provide a collection of quantitative data (e.g., frequency, signal strength, velocity, , i.e., statistics, 
which are used in determining motion). Alternatively, as per Table 1 , multiple scan periods are 
depicted. One period may be skipped in lieu of another based on the aforementioned analysis. 

50. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et 
al. (USPN 2006/0084417 Al) in view of Shi (USPN 6807163), in view over Hawkins (USPN 
7025209), and in further view over Lemilainen et al. (USPN 6681259) 

51. As per claim 49, Melpignano et al. teaches the computer-readable medium of claim 28, 
further comprising: 

receiving a notification that a new network interface is available ([0070-72] e.g., hardware 
update. It is obvious that interfaces may be added and removed); and 

However, Melpignano et al. does not teach loading another media specific module (e.g. 
network class information. It is obvious to have one class per network interface, providing a 
plurality of classes. One class corresponds to Bluetooth (e.g., type, status), another class 
corresponds to Wlan (e.g. type, status). Each class equates to a module. When a new interface 
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is added, a new module is created, as per Hawkins, see below) corresponding to said new 
network interface,. Hawkins teaches installing a network interface module, i.e., loading a media 
specific module, which would correspond to the new interface hardware, such as Bluetooth, 
where such modules contain code (e.g., drivers) configured to provide network information 
([Col 101 lines 6-14]) 

However, Melpignano et al, as modified (e.g., one class per interface type, where a class is a 
module), does not teach said media specific module (e.g., networkclass) configured to request 
network interface information from a driver for said network interface. Lemilainen et al. 
teaches NIC drivers provide features and state information ([Col 10 lines 1 1-30] e.g., this 
illustrates that drivers provide status information) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to enable the networkinterface class (e.g., module) to request status information using 
network interface drivers. Melpignano et al teaches that interface status is requested - element 
202 (ifStatusFlags). Lemilainen et al. teaches NIC drivers provide status information. 
Therefore, it would have been obvious to use NIC drivers to relay state information to the 
networkinterface module -element 202. As modified, there is a network interface module 
(element 202) for each type of module (e.g., Bluetooth, GPRS, WLan). As new interface cards 
are added, a new module, as per Hawkins, is added to reflect this addition. 
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Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to DARRIN DUNN whose telephone number is (571)270-1645. 
The examiner can normally be reached on EST:M-R(8:00-5:00) 9/5/4. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Albert DeCady can be reached on (571) 272-3819. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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/Albert DeCady/ 
Supervisory Patent Examiner 
Art Unit 2121 



